This invention generally relates to transactions using the World Wide Web; and more specifically, the invention relates to improving the security of such transactions.
The World Wide Web is the grounds where, on a broad scale, our society's business, government, and personal services are migrating and growing. As a basic model, a large population of clients with browsers obtain services from a smaller population of service providers operating Web servers. However, for each critical service that takes root in the Web (and arguably for many purely recreational services as well), the financial and personal interests of the clients force them to trust the integrity and privacy of the computation and data storage at the service providers.
Distributed computation (and even centralized computation, with multiple parties) introduces a fundamental problem: distribution dissociates dependency from control. Consider a basic scenario outlined in FIG. 1. In this example, Alice and Bob participate in some computational activity. Alice's interests I depends on some correctness and/or privacy properties P of some computation X at a computer that Bob controls. Consequently, Alice must depend on Bob to preserve and protect her interests. However, Bob may have no motivation to do this; and, in fact, Bob's interests may conflict with Alice's, and motivate him to actively subvert Alice's computation.
In the above example, dependency on remote computation went one way. However, the scenario can be more complex, as FIG. 2 shows. In this example, suppose Alice and Bob are users in a decentralized e-cash system, where cash is a value in a register in a wallet, and is exchanged by a protocol between the wallets. The computations XA, XB are the storage and appropriate alteration of the amount of money in Alice's wallet and Bob's wallet, respectively. The important security properties PA, PB of these computations are that the values in these wallets only increase under appropriate circumstances. Alice's interests IA include maximizing the amount of money she has, and preserving its value; Bob's interests IB are symmetric.
If Alice can break into her wallet, she can break PA; similarly, Bob can break PB. Alice's interests IA depend on PB holding; but Bob's interests IB motivate him to break PB. Symmetrically, Bob's interests depend on PA, which Alice is motivated to break.
All parties in this distributed e-cash system must trust all other parties; in a sense, the least-trusted user has the ability and the motivation to subvert the entire system.
Previous research had long speculated that programmable, trusted secure coprocessors could enable systematic solutions to problems such as FIG. 1. FIG. 3 illustrates a revised scenario. If X occurred in a secure coprocessor at Bob's machine, and Alice was able to authenticate that X was occurring there, beyond Bob's control, and Bob's ability to manipulate his host and its network connections could not subvert P, then Alice can trust that the important properties PB still hold of X, despite Bob's potential attacks.
As the popularity of the Web—and the recognition of its potential for applications with real security issues—spread, many proposals and ideas surfaced to add security to the basic http protocol. At one point, three primary contenders emerged:                i) Shen from CERN,        ii) Secure HTTP from a consortium including NCSA, and        iii) Secure Socket Layer (SSL), from Netscape.        
Primarily because Netscape's SSL protocol was the first to be widely deployed, SSL became the de facto standard for securing Web transactions.
As practiced, SSL permits the client to establish a shared symmetric key with a specific authenticated server. The server has a private-public keypair, and a certificate from some CA attesting to certain properties about the entity owning this public key. The client browser has some notion of which CA root keys it recognizes as valid. When a client opens an SSL connection, it verifies that the certificate from the server is correctly signed by a CA root that the client's browser currently recognizes as legitimate. The client and server then carry out a key generation/exchange protocol that ensures that the client, and a party which knows the private key matching the server's public key, share a symmetric key—that is (theoretically) shared by no one else, not even an adversary observing the messages between the client and server.
The remainder of the SSL session is then encrypted with this session key. Encryption with a key obtained this way provides several properties. Both parties can trust the privacy of data from the client to the server. Both parties can trust the privacy of data from the server back to the client. Both parties can trust that an adversary cannot alter or manipulate data in either direction without detection (since SSL provides integrity checking and sequence numbering). The client can trust the authenticity of the server (since the server entity must know the private key matching the public key in the certificate). The server can trust that, throughout the session, the entity claiming to be the client is the same entity that started the session. FIG. 4 shows a more detailed ladder diagram.
Even with the current state of deployed technology (i.e., SSL), however, all the client can know for sure is the identity of the entity who originally possessed the public key in that server's certificate.
At best, this identity establishes good intentions—if the alleged service provider has a pre-existing reputation that makes this hypothesis plausible. On the other hand, a service provider with an unknown reputation might be downright malicious. Also, any service provider may have good intentions, but may be careless with general site security. Moreover, the entity with which the client is currently interacting may not even be this original service provider, but rather an imposter who has learned the private key.
The threat that arises from this uncertainty is amplified by the Web's distribution of computation from server to client: via Java and Javascript, and also via more subtly executable content, such as Word documents infected with Macro viruses. Furthermore, many interactions involve more parties than just the client and server, but these additional parties are also forced to trust the server integrity.
This situation—that participants are forced to trust server integrity, but have no basis for this trust—is a fundamental problem threatening a wide variety of Web applications. Several of these applications are discussed below. These applications are shown herein to represent examples having missing security and/or privacy properties.
Authentication of Clients
The current Web infrastructure prevents a server from being able to prove anything to a third party about the identity of an alleged client. Without a public-key infrastructure for citizens, clients are forced to use human-usable authenticators, such as user ids and passwords. However, in the current infrastructure, these are exposed to the server of unknown integrity. As a consequence of this exposure, an adversary who compromises the server (or a malicious server operator) can impersonate this user at that site and any others where the client has used that password. This exposure also prevents legitimate server operators from being able to argue it really was a particular client who opened a particular a session. In this application, “user” and “client” are used interchangeably.
Nonrepudiation of Client Activity
The current Web infrastructure prevents a server from being able to prove anything to a third party about the activity of an alleged client. For example, how can an insurance company taking an application over the Web turn around and prove that a particular individual really answered that question that way?
Nonrepudiation of Server Activity
The current Web infrastructure prevents a server from being able to prove anything to a third party about the activity of the server—including the questions that generated the answers a client provided.
Credit Card Transaction Security
The current Web infrastructure provides secure transmission of a client's credit-card information and transaction amount to a server, where they are then exposed. An adversary who compromises this server (or a malicious server operator) can change the amount of the transaction, retain the amount but repeat the transaction many times, or use the credit card information to forge additional transactions. This situation may significantly reduce the potential market for new e-merchants without a pre-established reputation.
Taxes on E-Commerce Activity.
The current Web infrastructure provides no acceptable means for a third party with legitimate interests (such as a government's tax collection service) to accurately learn certain information about individual or collective Web interactions (such as how much sales tax an e-merchant owes them for last month). Reporting all transactions to the government would be unacceptable to the merchant and customer for privacy concerns; while reporting only a total amount owed would be unacceptable to the government, since the figure would be unverifiable, and the merchant reporting this unverifiable figure would be motivated to understate it.
Re-Selling of Intellectual Property
The current Web infrastructure provides no acceptable means for a third party who participates in an interaction indirectly, by licensing proprietary information to the server, to protect their legitimate interests. For example, a publisher who owns a large copyrighted image database might wish to make this available to a university library—but might worry that compromise of the university server will compromise the database.
Privacy of Sensitive or Proprietary Web Activity
The current Web infrastructure provides no means for a server operator to plausibly deny that they (or an adversary who has compromised their machine) is not monitoring all client interactions. How can companies that are accessing a competitor's server, know for sure that said competitor is not data-mining their queries? What about people who wish to purchase sensitive literature (about health topics, or currently unfashionable politics)? If an auction server provides a bulletin board service where customers can post “anonymous, confidential” comments, how do the customers know their identity is being kept secret? What about a server who is participating in an anonymous re-rerouting service?
Correctness of Web Activity
The current Web infrastructure provides no means for a server operator to establish that they (or an adversary who has compromised their machine) has not otherwise altered or corrupted important correctness properties of the service. In the auction bulletin board service described above, how can customers know that the anonymous posts came from bona fide customers, and that the timestamps are correct?
Enforcement of Logo/“Seal of Approval” Licenses
The current Web infrastructure provides no effective means for a party to ensure that logos or endorsements appear only on the appropriate server pages. For example, a company could establish an “inspected” logo to endorse servers who have withstood inspection by the ethical hackers of IBM Global Services. However, any client who visits these pages can capture the logo, and put it on any page.
Safety of Downloadable Content
The current Web infrastructure provides no means for the client to ensure that executable content downloaded from a server is indeed safe, short of the client themselves actually running the latest anti-virus software. Since most consumers do not do this, this leaves them at risk. Moving this computation (and the anti-virus update problem) to the server is more efficient—but how can clients know the server really carried this out?
Authenticity of Downloadable Content
The current web infrastructure provides no easy means for the client to authenticate the origin of downloadable content. Posters of content can provide digital signatures, but then the client needs to explicitly obtain and verify the trust chain on each item. Moving this computation (and the latest certificate revocation lists) to the server is more efficient—but how can clients know the server really carried this out?
Integrity of Server Machine
The current Web infrastructure provides no means for the client to recognize those servers whose hosts do run more secure operating systems or have more secure administrative practices. How can a consumer know for sure that a site really ran a particular network security analyzer or used a particular new secure boot system?